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Abstract 

This  paper  summarizes  a  novel  paradigm  for 
expressing,  enforcing,  and  formally  reasoning 
about  time-criticality  of  machine-to-machine 
resource  management  in  battle  management 
(BM)  and  C2  systems.  Such  systems  are  largely 
dynamic  and  asynchronous,  and  have  time 
frames  of  0(1 01)  seconds  and  higher.  Thus  they 
fall  into  a  neglected  gap  between  traditional 
static  periodic  “real-time”  systems,  and  tradi¬ 
tional  “any  time”  scheduling/planning  systems 
(e.g.,  for  logistics).  The  paradigm  uses  applica¬ 
tion-level  QoS  metrics  (such  as  track  quality, 
circular  error  probable,  etc.)  to  derive  utility 
functions  for  completing  tasks,  and  then  uses 
those  utility  functions  for  resource  management. 
This  paradigm  has  been  successfully  employed 
in  several  experimental  BM/C2  demonstration 
systems,  and  is  the  topic  of  on-going  research 
by  industry  and  academia. 
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Introduction 

A  system  provides  services,  each  of  which 
may  have  various  qualities.  Each  service  usually 
has  multiple  dimensions  of  quality.  Generic  ex¬ 
amples  include  timeliness,  availability,  and  se¬ 
curity.  Quality  of  service  (QoS)  is  traditionally 
associated  only  with  network  communications  - 
e.g.,  bandwidth,  BER,  latency  and  jitter.  But 
QoS  is  an  inherently  general  concept  that  can  be 
employed  at  any  levels  of  a  system  and  enter¬ 
prise. 

In  many  systems,  complex  dynamic  service  - 
and  thus  resource  -  conflicts  and  dependencies 


arise.  Resolution  of  the  resource  contention  af¬ 
fects  the  quality  of  the  provided  services  to  the 
users  and  thus  the  success  of  the  mission  and  the 
enterprise.  Not  all  service  requests  can  always 
be  perfectly  satisfied;  adaptive  situation  and  ap¬ 
plication-specific  resource  management  deci¬ 
sions  are  required. 

Some  of  the  service  requests  are  time-critical 
-  the  quality  of  the  service  depends  on  when  it 
is  performed.  The  timeliness  of  these  services 
may  have  potentially  drastic  impacts  on  the  en¬ 
terprise  and  its  mission,  including  survival  of 
property  and  human  lives. 

By  popular  convention,  the  term  “safety  criti¬ 
cal”  is  reserved  for  very  simple,  static,  systems 
that  can  be  developed  in  accordance  with  DO- 
178B  and  other  similar  standards.  But  many 
large  scale,  dynamic,  systems  (such  as  for  com¬ 
bat  platform  mission  management,  and  battle 
management)  have  at  least  as  much  potential  for 
human  harm  as  do  those  “safety  critical”  ones, 
yet  they  are  beyond  the  foreseeable  state  of  the 
art  in  high  assurance  in  the  spirit  of  DO-178B  et 
al.  In  the  absence  of  substantive  research  results 
on  that  problem,  assurance  must  be  sought  by 
design  methodologies,  simulations,  and  exten¬ 
sive  testing. 

In  this  paper  we  discuss  resolving  resource 
contention  by  adaptively  maximizing  total  ap¬ 
plication-level  quality  of  service  (“AQoS”)  of  a 
set  of  services  according  to  application-  and 
situation-specific  criteria.  Multimedia  and  simi¬ 
lar  applications  popular  in  the  real-time  research 
community  have  AQoS  metrics,  but  they  are 
isomorphic  to  the  QoS  metrics  of  traditional  net¬ 
working,  and  so  do  not  present  significantly 
new  resource  management  challenges  and  op- 


portunities.  We  are  concerned  with  managing 
application,  as  well  as  system,  resources  (hard¬ 
ware  and  software)  -  above,  as  well  as  at,  the 
network  level  -  using  AQoS  metrics,  such  as  (in 
most  systems  of  interest  to  us)  track  quality  and 
weapon  spherical  error  probable. 

Application  designers  often  think  in  terms  of 
what  we  refer  to  as  AQoS  metrics,  but  not  in  a 
general  and  methodological  way.  Instead,  they 
consider  certain  metrics  and  use  their  domain 
expertise  to  attempt  to  aggregate  these  into  the 
proper  “tuning”  of  the  system.  System  and  re¬ 
source  management  (OS,  middleware)  software 
designers  usually  do  not  think  in  terms  of 
AQoS.  Thus,  there  are  needs  for  systematizing 
and  quantifying:  the  expression  of  AQoS  met¬ 
rics,  and  the  potential  trade-offs  among  them,  to 
resource  management  software;  and  managing 
resources  adaptively  by  employing  AQoS  to 
dynamically  optimize  the  system’s  behavior  ac¬ 
cording  to  the  users’  wishes. 

We  are  particularly  interested  in  helping  meet 
those  needs  in  the  context  of  satisfying  applica¬ 
tion  timeliness  requirements.  We  are  focused  on 
using  AQoS  metrics  in  defining  how  each  ser¬ 
vice’s  timeliness  contributes  to  its  utility  to  the 
current  state  of  the  mission  and  sequencing  ac¬ 
cess  to  shared  resources  based  in  part  on  maxi¬ 
mizing  the  utility  accrued  from  the  set  of  ser¬ 
vices. 

Dynamic  Time-Critical  Control  Systems 

Many  important  time-critical  control  systems 
do  not  fit  the  “real-time”  stereotype  of:  being 
small  scale,  static,  periodic,  centralized;  per¬ 
forming  autonomic  monitoring  and  control  of 
simple  devices;  and  having  time  frames  in  the 
microsecond  and  millisecond  range.  Instead, 
they:  are  large  scale  in  various  dimensions  (e.g., 
millions  of  lines  of  source  code),  dynamic, 
“mesosynchronous,”  and  distributed;  perform 
closed  loop  automated  control  at  any  level(s)  of 
an  enterprise;  and  typically  operate  in  time 


frames  of  hundreds  of  milliseconds  to  several 
minutes. 

In  mesodynamics  [1],  the  prefix  mesa  refers 
to  the  middle  ground  between  classical  physics 
and  quantum  physics.  By  mesosynchronous 
real-time  systems  we  mean  those  that  are  in  the 
middle  ground  between  totally  synchronous  -  in 
the  sense  of  having  only  static,  periodic,  time- 
driven,  activities  (e.g.,  [2])  and  totally  asyn¬ 
chronous  -  in  the  sense  of  having  only  dynamic, 
aperiodic,  event-driven,  activities.  The  real 
world  has  many  important  real-time  control  sys¬ 
tems  at  various  points  in  this  mesosynchronous 
middle  ground.  The  derivation  of  “mesosyn¬ 
chronous”  from  “mesodynamics”  also  reflects 
that  synchronous  real-time  computing,  like  clas¬ 
sical  physics,  is  relatively  well  understood, 
while  asynchronous  real-time  computing,  like 
quantum  mechanics,  requires  a  paradigm  shift 
and  thus  a  great  deal  more  research  and  devel¬ 
opment  on  methodologies  and  formalisms. 

It  might  be  tempting  to  erroneously  interpret 
“mesosynchronous”  as  meaning  that  a  system  is 
composed  of  separate  traditional  synchronous 
static  hard  real-time,  and  asynchronous  dy¬ 
namic,  non-real-time  parts.  While  mesosyn¬ 
chronous  systems  normally  do  have  traditional 
synchronous  hard  real-time  parts,  the  asynchro¬ 
nous  parts  are  just  as  “real-time”  as  the  syn¬ 
chronous  ones  are.  And  some  parts  are  neither 
synchronous  nor  asynchronous  -  or  are  both. 
Properly  speaking,  a  real-time  activity  is  one 
that  has  a  completion  time  constraint.  Asyn¬ 
chronous  activities  may  have  deadlines,  even 
hard  deadlines  that  if  missed  result  in  opera¬ 
tional  failures  -  assurances  about  their  timeli¬ 
ness  are  based  on  adherence  to  resource  man¬ 
agement  policies,  and  are  almost  always  un¬ 
avoidably  non-deterministic.  More  commonly, 
these  activities  have  softer  but  more  complex 
time  constraints,  and  sequencing  optimality  cri¬ 
teria  that  are  softer  but  more  complex  than  sim¬ 
ply  always  meeting  all  deadlines  (e.g.,  minimize 
the  expected  completion  time  tardiness  accord- 


ing  to  activity  importance).  That  does  not  mean 
these  activities  are  in  any  way  less  “important” 
or  less  mission-critical  or  even  less  safety- 
critical  than  the  synchronous  activities  -  indeed, 
quite  the  contrary. 

The  application  domain  of  primary  interest  to 
us  is  defense.  Defense  systems  and  applications 
have  always  had  by  far  the  most  challenging 
time-critical  resource  management  problems  - 
and  are  MITRE’s  predominant  focus.  Examples 
include:  multi-role  and  multi-mode  sensors 
(e.g.,  phased  array  radars  such  as  MP-RTIP  [3]), 
combat  and  surveillance  platform  management 
(e.g.,  the  new  E-10A  (MC2A)  aircraft  [4], 
UAY’s  and  UCAV’s  [5],  the  DD(X)  class  of 
destroyers  [6],  the  Army  Future  Combat  System 
vehicle  cluster  [7],  battle  management  and  mis¬ 
sion  management,  (e.g.,  time-critical  targeting 
[8]),  command  and  control  (e.g.,  AW  ACS  [9]), 
and  network-centric  warfare  [10]. 

Time-critical  resource  management  in  net- 
work-centric  warfare  is  exemplified  by  the  Af¬ 
fordable  Moving  Surface  Target  Engagement 
(AMSTE)  system  [11],  a  notional  non-classified 
depiction  of  which  is  in  Figure  1.  AMSTE  in¬ 
cludes  netted  airborne  and  spacebome  Ground 
Moving  Target  Indication  (GMTI)  sensors  for 
tracking  a  target  on  the  ground,  a  missile 
launching  fighter  aircraft,  and  a  missile  guid¬ 
ance  aircraft  (which  is  usually  one  of  the  sensor 
aircraft).  The  targets  are  moving  or  alternately 
moving  and  stopping.  The  AMSTE  objectives 
are:  to  maintain  target  track  from  nomination 
through  engagement,  from  tactically  significant 
standoff  ranges;  and  to  provide  precision  fire 
control  updates  to  missiles  in  flight.  These  ob¬ 
jectives  require  time-critical  orchestration  of 
multiple  sensors,  data  links,  and  the  missile.  The 
control  loop  has  about  a  one  second  time  con¬ 
straint  for  sensor  to  tracker  to  missile,  and  about 
an  eight  Hz  update  rate  to  the  missile  (the  de¬ 
tails  of  an  actual  AMSTE  system  are  classified). 
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Figure  1.  Notional  depiction  of  an  AMSTE 
system 

The  milliseconds-to-minutes  time  scale  is  in  a 
“no  man’s  land”  of  time-critical  resource  man¬ 
agement  theory  and  practice,  between  conven¬ 
tional  real-time  scheduling,  and  classical  logis¬ 
tics  (e.g.,  shop)  scheduling  with  deadlines.  Con¬ 
ventional  real-time  scheduling  concepts  and 
techniques:  are  for  static  (deterministic),  peri¬ 
odic,  and  (to  a  degree)  sporadic  activities,  and 
cannot  handle  arbitrary  asynchrony  and  dy¬ 
namic  changes  in  load  and  resources;  time- 
frames  are  presumed  to  be  in  the  microseconds 
to  milliseconds  range,  which  limits  resource 
management  algorithm  capability.  Classical  lo¬ 
gistics  scheduling  concepts  and  techniques  [12] 
include:  stochastic  as  well  as  deterministic 
models;  but  time-frames  are  in  the  minutes  to 
hours  (usually  too  computationally  intensive  for 
on-line  automated  resource  management);  and 
the  use  of  lateness  (deadline  -  completion  time) 
as  the  timeliness  metric,  the  linearity  of  which 
severely  limits  time  constraint  expressiveness. 

Time/Utility  Functions  and  Utility  Accrual 

In  1977  Jensen  created  a  novel  scheduling 
paradigm  for  dynamic  time-critical  systems  [13] 
for  the  U.S.  Army  Safeguard  Command's 
AN/FPQ-16  Perimeter  Acquisition  Radar  Char¬ 
acterization  System  [14],  located  at  what  is  now 
the  USAF  Space  Command's  Cavalier  Air  Force 
Station,  in  Cavalier,  North  Dakota.  The  sys¬ 
tem’s  radar  performance  was  not  up  to  expecta¬ 
tions.  Simulated  performance  with  the  new 
scheduling  paradigm  was  sufficiently  improved 


that  the  paradigm  was  deemed  to  possibly  vio¬ 
late  SALT  II,  and  hence  was  not  deployed. 
From  then  until  now,  Jensen  and  his  collabora¬ 
tors  have  continued  to  develop,  refine,  and  ap¬ 
ply  the  paradigm.  At  Carnegie  Mellon’s  Com¬ 
puter  Science  Department,  two  of  Jensen’s 
Ph.D.  students  wrote  their  theses  on  this  topic 
[15,16]  -  devising  new  scheduling  algorithms, 
proving  theorems  about  them,  simulating  them, 
and  implementing  them  in  our  Alpha  real-time 
distributed  OS  kernel  [17].  Subsequent  en¬ 
hancements  have  also  been  made  by  other  re¬ 
searchers  (e.g.,  [18,  19,  20,  21]). 

The  two  keystone  concepts  in  our  paradigm 
are  time/utility  functions  (originally  called 
time/value  and  then  benefit,  functions)  and  util¬ 
ity  accrual  sequencing  (scheduling,  dispatching) 
optimality  criteria  [13,  22], 

A  time/utility  function  (TUF)  expresses  the 
utility  to  the  system  (derived  from  AQoS  met¬ 
rics)  of  completing  an  activity  (e.g.,  service)  as 
an  application-  or  situation-specific  function  of 
when  it  completes.  Deadlines  are  a  simple  spe¬ 
cial  case,  where  full  utility  is  achieved  if  the  ac¬ 
tivity  completes  by  its  deadline,  and  zero  (or 
some  negative)  utility  is  achieved  if  it  completes 
after  its  deadline.  Four  example  TUF’s  are  de¬ 
picted  in  Figure  2. 


Figure  2.  Four  example  time/utility  functions 

Utility  accrual  (UA)  based  sequencing  algo¬ 
rithms  sequence  activities  according  to  optimal¬ 
ity  criteria  based  on  accruing  utility  -  such  as 
maximizing  the  sum  of  the  utilities  (plus  satisfy¬ 
ing  dependencies  such  as  precedence,  resource 


constraints,  etc.).  The  algorithms  take  into  ac¬ 
count  the  known  or  expected  durations  of  the 
activities,  and  may  be  either  deterministic  or 
non-deterministic  (e.g.,  stochastic). 

Worked  Examples 

To  illustrate  the  use  of  this  paradigm,  we 
summarize  two  significant  (unclassified)  dem¬ 
onstration  applications  we  implemented  suc¬ 
cessfully  in  collaboration  with  application  do¬ 
main  experts. 

AWACS Surveillance  Tracker 

The  first  application  is  an  AWACS  surveil¬ 
lance  tracker  [23],  implemented  jointly  by  the 
MITRE  Corporation  and  the  Open  Group. 
AWACS  is  an  airborne  radar  system  with  varied 
missions,  including  air  surveillance.  Surveil¬ 
lance  missions  generate  aircraft  tracks  for  battle 
management  and  command  and  control.  It  is 
very  common  for  there  to  be  too  many  radar  re¬ 
ports  for  the  computing  system  to  process, 
which  causes  sectors  of  the  sky  to  “go  blank”. 
Higher  performance  computing  only  helps 
somewhat,  because  the  potential  report  load  and 
the  need  for  ever-better  tracking  algorithms  will 
always  exceed  all  the  computing  capacity.  Cur¬ 
rently,  operators  have  knowledge-intensive 
manual  work-arounds  for  certain  overload  situa¬ 
tions. 

The  surveillance  mission  includes  a  number 
of  activities;  for  brevity  here,  we  consider  only 
the  most  computationally  demanding  activity, 
association,  which  associates  radar  reports  with 
tracks.  There  is  a  multiplicity  of  concurrent  as¬ 
sociation  threads,  one  for  each  current  radar  re¬ 
port. 

There  are  two  sensors  (radar  and  IFF)  sweep¬ 
ing  180°  out  of  phase  with  a  10-second  period, 
which  suggests  the  association  TUF  has  a  “criti¬ 
cal  time”  at  the  10-second  period  length,  at  least 
two  distinct  non-zero  utilities  before  the  critical 
time,  and  a  third  distinct,  lower,  utility  after  the 
critical  time. 


Prior  to  the  critical  time,  processing  a  sensor 
report  for  one  of  these  tracks  in  under  five  sec¬ 
onds  (half  the  sweep  period)  would  provide  bet¬ 
ter  data  for  the  corresponding  report  from  the 
out-of-phase  sensor.  So  the  utility  decreases 
with  time.  The  TUF  had  to  decrease  linearly  due 
to  an  implementation  artifact  in  this  experimen¬ 
tal  system  -  the  OS  (OSF/RI’s  MK7  [24])  TUF 
scheduling  algorithm  allowed  only  one  critical 
time.  The  slope,  and  thus  U2,  were  derived  em¬ 
pirically  (systematizing  this  process  is  one  of 
our  current  research  topics). 

After  the  critical  time,  utility  is  zero,  because 
newer  sensor  data  has  probably  arrived  if  the 
processing  load  in  one  sensor  sweep  period  is  so 
heavy  that  it  couldn’t  be  completed,  probably 
the  load  will  be  about  same  in  next  period,  so 
there  will  be  no  capacity  to  also  process  data 
from  the  previous  sweep.  A  tracker  that  could 
process  older  as  well  as  current  data  would  be 
significantly  more  complex  and  probably  delay 
the  track  update.  The  resulting  TUF  shape  is 
shown  in  Figure  3. 


critical  time  (sweep  period  length) 

Figure  3.  Association  time/utility  function 
shape 

Next,  the  utility  value  Ui  had  to  be  deter¬ 
mined.  To  do  that,  we  used  well-established 
surveillance  tracker  AQoS  metrics,  which  are 
based  on  the  tracker  domain  experts’  knowledge 
about  how  to  manually  attempt  to  resolve  con¬ 
tention  for  resources: 

•  Don’t  drop  tracks,  because  they  are  ex¬ 
pensive  to  re-create 


•  User-identified  “important”  tracks  re¬ 
ceive  preference 

•  User-identified  “important”  geographic 
regions  receive  preference 

•  Maneuvering  tracks  need  to  be  updated 
more  frequently  than  non-maneuvering 
tracks 

•  Potentially  high  threat  tracks  receive 
preference 

•  High  speed  tracks  receive  preference 

•  Tracks  with  poor  state  estimates  receive 
preference. 

Conventionally,  tracker  domain  experts  aren’t 
provided  with  computation  technology  that 
would  give  them  incentives  to  use  their  knowl¬ 
edge  to  understand  and  express  behavioral  op¬ 
tions  and  trade-offs  in  the  face  of  dynamic  un¬ 
certainties  (i.e.,  gracefully  handling  overloads) 
that  plague  current  trackers.  Our  intention  was 
to  provide  technology  that  would  utilize  track¬ 
ing  domain  expertise  sufficient  to  automate  the 
adaptive  assignment  of  the  right  resources  to  the 
right  tasks  at  the  right  time. 

We  chose  three  (to  limit  the  complexity  of  the 
experimental  system)  AQoS  metrics  for  an 
AWACS  surveillance  tracking  application  (a 
decision  with  which  the  domain  experts  con¬ 
curred): 

•  Quality  -  0  to  7:  a  traditional  measure 
of  the  amount  of  recent  sensor  data  in¬ 
corporated  in  a  track  record,  and  incre¬ 
mented  or  decremented  after  each  radar 
scan 

•  Accuracy  -  “high”  or  “low”:  a  measure 
of  the  uncertainty  of  the  estimate  of  a 
track’s  position  and  velocity  and  derived 
from  Kalman  filter  processing 

•  Importance  -  “high”  or  “low”:  tradi¬ 
tionally,  operator-identified  based  on 
geography,  threat,  and  other  characteris¬ 
tics. 


The  twelve  combinations  of  these  three 
AQoS  metrics  are  diagrammed  in  Figure  4. 

The  initial  utility  Ui  of  an  association  for  a 
track  report  is  derived  from  track  AQoS  metrics 
by  gedanken  experiments.  The  utilities  range 
from  a  low  of  10  to  a  high  of  6000  -  meaning 
that  600  times  more  utility  is  gained  by  per¬ 
forming  an  association  for  a  low  accuracy,  high 
importance,  poor  quality  track,  than  for  a  high 
accuracy,  low  importance,  high  quality  track. 


Track  Importance  Track  Accuracy 


Track  state 

T rack  state 

Track  state 

poor 

marginal 

OK 

Figure  4.  The  12  Combinations  of  track 
AQoS’s  and  their  relative  utilities 

All  the  association  (and  other)  threads  are 
scheduled  based  on  their  utility  functions.  For 
the  association  threads,  the  tracking  application 
selects  the  established  TUF  from  the  scheduler’s 
library  of  shapes.  The  tracking  application  does 
a  look-up  in  the  utility  U|  table  for  each  asso¬ 
ciation  thread  before  calling  the  scheduler.  A 
utility  accrual  based  processor  scheduling  disci¬ 
pline  (in  the  OS,  in  this  system)  schedules 
threads  according  to  a  heuristic  that  attempts  to 
maximize  total  accrued  (in  this  case,  summed) 
utility. 

This  surveillance  tracking  application  was 
implemented  on  a  research  OS  (the  Open  Soft¬ 
ware  Foundation’s  MK7)  having  a  scheduling 


framework  that  allowed  different  disciplines  to 
be  used.  Figure  5  shows  two  critical  tracker 
AQoS  metrics,  the  number  of  dropped  tracks 
and  track  quality,  for  more  and  less  important 
threads,  using  three  scheduling  disciplines: 
FIFO  (the  discipline  used  in  the  currently  de¬ 
ployed  AW  ACS  tracker);  priority  (the  predomi¬ 
nant  discipline  in  real-time  computing  systems); 
and  one  of  our  utility  accrual  disciplines. 

In  the  measured  cases  shown,  under  non¬ 
overload  conditions,  the  tracker  handled  all 
tracks  as  expected  and  delivered  high  AQoS  in 
both  metrics  for  all  tracks.  In  an  overload  sce¬ 
nario,  such  as  when  the  tracker  can  only  process 
about  33%  of  the  input,  the  system  delivered 
essentially  perfect  track  quality  for  the  more 
important  tracks,  while  delivering  a  reasonable 
track  quality  for  the  less  important  tracks.  (In 
some  respects,  this  overload  level  can  be  lik¬ 
ened  to  a  system  where  the  probability  of  de¬ 
tecting  an  airborne  object  is  about  33%.)  When 
the  tracker  was  further  constrained  so  that  it 
could  only  process  about  10%  of  the  input,  the 
system  finally  dropped  some  tracks  -  from  the 
less  important  track  class.  No  important  tracks 
have  been  dropped  during  our  demonstrations. 
In  addition,  the  demonstrations  have  shown  that 
the  tracker  also  adapts  when  new  resources  are 
added.  In  that  case,  which  we  demonstrate  by 
loosening  the  time  constraints  on  association 
processing,  the  prototype  automatically  delivers 
approximately  the  maximum  achievable  AQoS. 

Note  that  these  results  are  not  easily  obtain¬ 
able  with  static  priority  tracking  systems.  In  pri¬ 
ority-based  trackers,  track  priorities  might  rea¬ 
sonably  be  set  according  to  track  importance, 
where  high  importance  implies  high  priority.  In 
our  tracker,  scheduling  decisions  are  based  on 
both  importance  and  timeliness,  and  even  rela¬ 
tively  unimportant  tracks  can  have  very  high 
application  utility  in  a  surveillance  mission  -  an 
outcome  that  would  not  be  possible  with 
straightforward  priority-based  scheduling. 
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Figure  5.  Comparison  of  AWACS  surveillance  tracker  AQoS  metrics  for  different  scheduling 

disciplines 


Battle  Management  for  Coastal  Air  Defense 

The  second  application  is  a  notional  battle 
management  system  for  coastal  defense  from 
cruise  missiles  and  bombers  [25],  It  was  imple¬ 
mented  collaboratively  by  the  General  Dynamics 
Corporation  and  Jensen’s  Archons  Project  at  Car¬ 
negie  Mellon  University’s  Computer  Science 
Department.  It  is  included  here  to  further  illus¬ 
trate  the  dynamic  adaptivity  possible  with 
time/utility  functions,  which  would  be  difficult  to 
achieve  with  priorities  or  even  deadlines. 

This  system’s  mission  is  to  destroy  incoming 
hostile  cruise  missiles  (for  brevity  here  we  will 
disregard  the  hostile  bombers),  by  using  guided 
interceptor  missiles.  There  may  be  more  cruise 
missiles  and  decoys  than  can  be  intercepted,  due 
to  the  number  of  cruise  missiles,  insufficient  in¬ 
terceptors,  and  insufficient  computational  re¬ 
sources  for  battle  management.  Cruise  missiles 
maneuver  during  flight,  but  do  not  try  to  evade 
the  interceptors.  Interceptors  are  guided  by  air¬ 
borne  defenders  using  airborne  (AWACS,  etc.), 


spacebome,  and  ground  based,  sensor  platform 
data. 

The  cruise  missile  defense  (CMD)  application 
quality  of  service  (AQoS)  metric  here  is  the 
weapon  spherical  error  probable  (WSEP). 
Spherical  error  probable  (SEP)  is  the  radius  in 
meters  of  a  sphere  centered  on  a  point  (e.g.,  the 
cruise  missile)  within  which  the  true  value  of  an 
estimated  point  (e.g.,  the  interceptor  missile)  will 
lie  with  a  probability  of  0.5.  The  WSEP  is  an  SEP 
radius  around  the  cruise  missile  chosen  such  that 
if  the  interceptor  gets  within  that  distance,  the 
interceptor’s  terminal  guidance  system  can  take 
over  and  with  p=0.5  cause  the  interceptor  to  ei¬ 
ther  impact  the  cruise  missile  or  detonate  close 
enough  to  the  cruise  missile  to  destroy  it. 

Some  CMD  AQoS  optimality  objectives  are: 

•  minimizing  WSEP 

•  intercepting  sooner  (further  from  the 
cruise  missile’s  target)  is  better  (EMP, 
etc.) 


•  intercepting  before  the  cruise  missile 
reaches  its  target  is  better 

•  intercepting  away  from  an  adverse  geo¬ 
graphical  location  (e.g.,  over  a  populated 
area)  is  better 

•  intercepting  before  the  blast  damage  to 
the  cruise  missile’s  target  from  the  com¬ 
bined  cruise  missile  and  interceptor  mis¬ 
sile  would  exceed  the  blast  damage  from 
the  cruise  missile  explosion  alone  is  bet¬ 
ter. 

WSEP  is  affected  by  several  factors,  including: 

•  guidance  updates  to  the  interceptor  are 
repetitive  but  not  necessarily  periodic  or 
even  sporadic,  and  need  to  occur  more  of¬ 
ten  as  the  interceptor  gets  closer  to  the 
cruise  missile 

•  it  becomes  more  important  to  use  the 
most  recent  information  about  the  posi¬ 
tions  and  velocities  of  the  missiles  as  the 
distance  between  the  cruise  missile  and 
the  interceptor  decreases 

•  some  cruise  missile  targets,  and  thus 
cruise  missiles,  are  more  important  than 
others. 

The  CMD  application  consists  of  a  number  of 
activities,  as  depicted  in  Figure  6. 

Tracking 

Gather  &  Fuse  Sensor  Update  Track  Data- 


Mission  Planning 


Activate  SAM 


Figure  6.  The  coastal  air  defense  battle 
management  activities 

Some  activities  resemble  corresponding  activi¬ 
ties  in  the  AWACS  surveillance  tracker.  The  plot 
correlation  and  track  database  maintenance 
threads  have  critical  times  corresponding  to  the 
radar  frame  arrival  rate.  In  both  cases,  it  is  better 
if  the  processing  is  completed  before  the  next 
frame  of  sensor  data  arrives.  It  is  acceptable  for 
the  processing  to  slip  as  much  as  one  additional 
time  frame  under  extreme  overload  situations. 
The  plot  correlation  activity  has  a  much  greater 
utility  to  the  system  under  overload  conditions. 
The  TUF’s  for  those  two  threads  are  shown  in 
Figures  7a  and  7b. 


Figures  7  a,b.  The  plot  correlation  and  track 
database  time/utility  functions 

But  the  timeliness  requirements  for  the  inter¬ 
ceptor  missile  control  threads  are  more  complex 
because  they  vary  over  the  course  of  an  intercep¬ 
tion  engagement.  After  an  interceptor  is 
launched,  the  guidance  control  threads  must  issue 
timely  aperiodic  course  updates  to  ensure  a  suc¬ 
cessful  intercept.  The  required  timeliness  of 
these  updates,  and  the  importance  of  completing 
the  course  corrections  at  the  desired  time,  change 
as  the  distance  decreases  between  the  interceptor 
and  the  cruise  missile,  and  between  the  cruise 
missile  and  the  coastline.  Each  interceptor’s  con¬ 
trol  thread  changes  three  parameters  of  its  shape 
during  the  engagement,  as  shown  in  Figure  8. 
Figure  9  shows  three  representative  snapshots  of 
this  adaptivity  as  it  progresses  from  right  (launch) 
to  left  (intercept). 
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Figure  8.  The  interceptor  time/utility  function 
has  three  shape  parameters  that  adapt  during  the 
engagement 


Figure  9.  Three  representative  snapshots  of  the 
interceptor  time/utility  function  adapting  during 
the  engagement 

This  effect  is  extremely  difficult  to  achieve  by 
manipulating  priorities  or  deadlines. 

Conclusion 

Our  current  research  objective  on  this  topic  is 
to  advance  this  paradigm’s  concepts  and  tech¬ 
niques,  and  to  explore  its  applications  in  the 
BM/C2  domain.  We  are  devising  new  resource 
management  algorithms,  proving  timeliness  and 
other  properties,  doing  simulations  of  them, 
building  and  measuring  experimental  implemen¬ 
tations  of  them,  devising  a  methodology  for  users 
to  apply  the  paradigm,  and  constructing  a  proof 
of  concept  software  tool  to  facilitate  the  method¬ 
ology. 
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Summary 


□  This  presents  a  novel  paradigm  for  expressing,  enforcing,  and 
formally  reasoning  about  time-criticality  of  machine-to-machine 
resource  management  in  battle  management  (BM)  and  C2 
systems 

□  Such  systems  are  largely  dynamic  and  asynchronous,  and 
have  time-critical  actions  in  the  0(1 0_1  -103)  seconds 

□  Thus  they  fall  into  a  neglected  gap  between  traditional  static 
periodic  “real-time”  systems,  and  traditional  “any  time” 
scheduling/planning  systems  (e.g.,  for  logistics) 

□  The  paradigm  uses  application- level  QoS  (AQoS)  metrics  (such 
as  track  quality,  circular  error  probable,  etc.)  to  derive  utility 
functions  for  completing  tasks, 

and  then  uses  those  utility  functions  for  resource  management 

□  This  paradigm  has  been  successfully  employed  in  several 
experimental  BM/C2  demonstration  systems 

□  It  is  the  topic  of  active  research  in  academia  and  industry 


MITRE 


3 


Many  important  time-critical  systems 

(such  as  for  BM/C2)  have  significant  dynamic  actions 


□  Many  important  time-critical 
control  systems  do  not  fit  the 
“real-time”  stereotype  of 

*  small  scale 

•  static 

•  periodic 

*  centralized 

•  performing  monitoring  and 
control  of  simple  devices 

*  time  frames  in  the 
microsecond  and  millisecond 
range 


□  Instead,  they  are 

•  large  scale  in  various 
dimensions 

•  dynamic 

•  “mesosynchronous” 

•  distributed 

•  performing  closed  loop 
machine-to-machine  control  at 
any  level(s)  of  an  enterprise 

•  operating  in  the  second  to 
minutes  time  frame 
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Priorities  have  severe  limitations, 
especially  in  dynamic  systems 
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□  Priorities  are  widely  used  in  time-critical  systems,  but  they 
have  major  disadvantages,  including 

•  priority  assignments  are  not  modular  -  they  require  global 
knowledge  of  all  other  priority  assignments  (whereas  time 
constraints,  such  as  deadlines,  do  not) 

9  the  granularity  of  time  constraints  is  typically  much  finer  than 
that  of  priority  ranges,  and  mapping  time  constraints  to  priorities 
is  NP-hard 

•  semantics  are  associated  with  priorities  by  the  users,  the  system 
and  application  software,  and  the  hardware 

>  sometimes  priorities  (artificially)  denote  urgency 

>  sometimes  priorities  denote  relative  importance 

>  sometimes  priorities  denote  execution  precedence 

□  Managing  the  assignments  and  changing  of  priorities  is  one  of 
the  most  notoriously  difficult  and  time-consuming  activities  in 
the  life  cycle  of  systems 
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Priorities  are  a  Procrustean  Bed 


□  Priorities  are  the  primary  mechanism  offered  in  COTS  (and 
application)  software  for  managing  timeliness,  so  designers 
and  users  must  try  to  force-fit  time  constraints  into  priorities 
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Deadlines  are  an  explicit  time  constraint 
but  have  limited  expressiveness 
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□  Deadlines,  as  popularly  spoken  of  in  “hard”  real-time  computing, 
are  only  binary:  an  action  either  meets  or  misses  it 


t 


meet 


miss 


deadline  =  t(1 

but  in  most  real  world  cases,  lateness  is  the  actual  criterion 


□  Scheduling  theory  deals  with  lateness,  but  deadlines  have  only 


•  linear  timeliness  metric,  lateness  =  completion  time  -  deadline 
9  single  inflection  point  metric,  tardiness  =  max[0, lateness] 


MITRE 


“Hard”  deadlines  and  general  deadlines  can  be 
represented  by  utility  as  a  function  of  time 
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□  A  “hard”  deadline  is  a  binary  unit-valued  downward  step 

meet  =  u  =  1  u 

t  | 

i  : 

1  i 

i  i 

miss  =  u  =  0  ► 


□  A  general  deadline  in  terms  of  lateness  and  negative  lateness 
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The  two  keystone  concepts  in  our  paradigm  are 
time/utility  functions  and  utility  accrual  scheduling 
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□  Jime/utility  functions  (TUF’s) 

•  express  the  utility  to  the 
system  (derived  from  AQoS 
metrics)  of  completing  an 
activity  (e.g.,  service)  as  an 
application-  or  situation- 
specific  function  of  when  it 
completes 


Example 


General  time/utility  functions 


■  ■  ■  Expected  or  max  execution  time 
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The  two  keystone  concepts  in  our  paradigm  are 
time/utility  functions  and  utility  accrual  scheduling 
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Example 


□  Utility  accrual  (UA)  scheduling 
algorithms 

*  schedule  activities  according 
to  optimality  criteria  based  on 

>  accruing  utility  -  such  as 
maximizing  the  sum  of 
the  utilities 

>  satisfying  dependencies 
such  as  resource 
constraints,  etc. 


General  time/utility  functions 


■  ■  ■  Expected  or  max  execution  time 
■  Example  scheduled  completion  times 


Schedule  to  maximize 

U  =  ZUi  - 
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Worked  examples  using  TUF/UA  scheduling 


□  This  paradigm  has  been  applied  in  significant  size  BM/C2 
demonstration  systems 

□  Next  we  illustrate  the  paradigm  in  the  context  of  an  air 
surveillance  tracking  application 

□  Then  we  show  one  facet  of  the  paradigm’s  use  -  not  employed 
in  the  surveillance  tracker  -  in  a  cruise  missile  defense 
application 

□  Another  major  demonstration  application  is  currently  being 
constructed  but  cannot  be  discussed  here 
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TUF/UA  sequencing  paradigm  worked  example  1: 
AWACS  air  surveillance  mode  tracker 
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□  MITRE  (with  collaboration  from  the  Open  Group)  applied  our 
paradigm  in  a  demonstration  AWACS  system 

□  Implemented  the  AWACS  air  surveillance  mission 

□  It  is  easy  and  common  for  there  to  be  so  many  sensor  reports 
that  the  system  becomes  computationally  overloaded,  which 
causes  sectors  of  the  sky  to  “go  blank” 

□  Currently,  operators  have  knowledge-intensive  manual  work¬ 
arounds  for  certain  overload  situations 

□  Our  objective  was  to  improve  graceful  overload  handling  by 
automatically 

9  applying  the  right  computational  resources 
9  to  the  right  tracks 
9  at  the  right  times 
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Tracking  system: 
original  and  adaptive 
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The  AWACS  sensor  properties  imply  a  general  utility 
function  for  the  association  computation 


□  Association  is  the  most  computationally  demanding  part  of 
tracking,  so  we  focus  on  that  in  this  presentation 

□  There  are  two  sensors  (radar  and  IFF)  sweeping  180°  out  of 
phase  with  a  10-second  period, 

which  suggests  the  TUF  has 

9  a  “critical  time”  at  the  10-second  period  length 

9  at  least  two  distinct  non-zero  utilities  before  the  critical  time 

9  a  third  distinct,  lower,  utility  after  the  critical  time 
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action  completion  time 


critical  time  (sweep  period  length) 
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Determine  the  thread  TUF  shape 
prior  to  the  critical  time 
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□  Prior  to  the  critical  time 

9  processing  a  sensor  report  for  one  of  these  tracks  in  under  five 
seconds  (half  the  sweep  period)  would  provide  better  data  for  the 
corresponding  report  from  the  out-of-phase  sensor 

so  the  utility  decreases  with  time 

9  the  TUF  had  to  decrease  linearly  due  to  an  implementation  artifact 
in  this  experimental  system  - 

the  OS  (OSF/RI’s  MK7.3A)  TUF  scheduling  algorithm  allowed  only 
one  critical  time 

9  the  slope  was  derived  empirically 
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Determine  the  thread  TUF  shape 
after  the  critical  time 
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□  After  the  critical  time 

9  utility  is  zero,  because  newer  sensor  data  has  probably  arrived 

9  if  the  processing  load  in  one  sensor  sweep  period  is  so  heavy  that 
it  couldn’t  be  completed, 

probably  the  load  will  be  about  same  in  next  period,  so  there  will 
be  no  capacity  to  also  process  data  from  the  previous  sweep 

9  a  tracker  that  could  process  older  as  well  as  current  data  would 

>  be  significantly  more  complex 

>  probably  delay  the  track  update 
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That  established  the  TUF  shape 
for  the  tracker’s  association  threads 
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□  A  critical  time  at  the  sweep  period  length 

□  Linearly  decreasing  utility  until  the  critical  time 

□  Zero  utility  after  the  critical  time 

□  Next,  the  utility  value  U1  had  to  be  determined 


u  f 


i 

critical  time  (sweep  period  length) 
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Tracker  domain  experts’  preferences  in  terms  of 
track  QoS  metrics  imply  the  thread  utility  values 
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□  Don’t  drop  tracks,  because  they  are  expensive  to  re-create 

□  User-identified  “important”  tracks  receive  preference 

□  User-identified  “important”  geographic  regions  receive 
preference 

□  Maneuvering  tracks  need  to  be  updated  more  frequently  than 
non-maneuvering  tracks 

□  Potentially  high  threat  tracks  receive  preference 

□  High  speed  tracks  receive  preference 

□  Tracks  with  poor  state  estimates  receive  preference 
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Three  application-level  QoS  metrics  for  an  AWACS 
surveillance  tracking  application  were  chosen 
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□  Quality  -  0  to  7 

•  traditional  measure  of  the  amount  of  recent  sensor  data 
incorporated  in  a  track  record 

•  incremented  or  decremented  after  each  radar  scan 

□  Accuracy  -  “high”  or  “low” 

9  a  measure  of  the  uncertainty  of  the  estimate  of  a  track’s  position 
and  velocity 

9  derived  from  traditional  Kalman  filter  processing 

□  Importance  -  “high”  or  “low” 

9  traditionally,  operator-identified  based  on  geography,  threat,  and 
other  characteristics 
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We  established  12  combinations  of  track  AQoS  metrics 
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What  are  the  relative  utilities  of  these  12  cases  of  tracks? 
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The  initial  utility  Uj  of  an  association  for  a  track  report  is 
derived  from  track  AQoS  metrics  by  gedanken  experiments 
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Domain  experts  judgment  on  the  relative  utilities  of  these  12  cases  of  tracks 
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The  initial  utility  Uj  of  an  association  for  a  track  report  is 
derived  from  track  AQoS  metrics  by  gedanken  experiments 
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Track  Accuracy 


t 

E.g.,  completing 
an  association  for 
a  high 

importance,  low 
accuracy,  low 
quality  track 
yields  600  times 
more  utility  than 
for  a  low 
importance,  high 
quality,  high 
accuracy  track 


Domain  experts  judgment  on  the  relative  utilities  of  these  12  cases  of  tracks 
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The  association  (and  other)  threads  are  scheduled 
based  on  their  utility  functions 
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□  For  the  association  threads,  the  tracking  application  selects  the 
established  TUF  from  the  OS  scheduler’s  library  of  shapes 

□  The  tracking  application  does  a  look-up  in  the  utility  U1  table  for 
each  association  thread  before  calling  the  OS  scheduler 

□  A  utility-based  processor-scheduling  policy  in  the  OS  schedules 
threads  according  to  a  heuristic  that  attempts  to  maximize  total 
accrued  (in  this  case,  summed)  utility 
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Utility-based  scheduling  provided  better  AQoS 
than  traditional  FIFO  and  priority  scheduling 
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FIFO 

Avg.  #  Dropped  Tracks  versus  Association 
Capacity  For  FIFO  Priority 


Priority 


Avg.  #  Dropped  Tracks  versus  Association 
Capacity  For  Fixed  Priority 


Utility-Based 

Avg.  #  Dropped  Tracks  versus  Association 
Capacity  For  Dynamic  Priority 
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Key: 

Track  Quality:  0-7  (7  =  Ideal) 
Association  Capacity  =  #  Tracks 
Processed  under  Constraint 
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TUF/UA  sequencing  paradigm  worked  example  2: 
cruise  missile  defense  with  guided  interceptors 


Plot  Track  Track 

Sensors  Correlator  DB  Hdlr 


Track  Threat  Stores  Weapon 

ID  Assessor  Mgr  Ctlrs 
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Distributable  Threads:  a  programming  model  for  end-to-end 
timeliness  in  distributed  systems  -  created  by  Jensen’s  CMU 
Alpha  OS  team  and  now  in  Real-Time  CORBA  1.2  (nee  2.0) 


The  timeliness  requirements  for  the  interceptor  missile 
control  threads  vary  over  the  course  of  an  engagement 


25 


□  After  launch  of  the  interceptor,  the  guidance  control  threads  must 
issue  timely  repetitive  course  updates  to  ensure  a  successful  intercept 


□ 


The  required  timeliness  of  these  updates,  and  the  importance  of 
completing  the  course  corrections  at  the  desired  time,  change  as  the 
distance  decreases  between  the  interceptor  and  the  cruise  missile,  and 
between  the  cruise  missile  and  its  expected  target 


intercept 


□  This  effect  is  very  difficult  to  achieve  by  manipulating  priorities 
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□  After  launch  of  the  interceptor,  the  guidance  control  threads  must 
issue  timely  repetitive  course  updates  to  ensure  a  successful  intercept 

□  The  required  timeliness  of  these  updates,  and  the  importance  of 
completing  the  course  corrections  at  the  desired  time,  change  as  the 
distance  decreases  between  the  interceptor  and  the  cruise  missile,  and 
between  the  cruise  missile  and  its  expected  target 


□  This  effect  is  very  difficult  to  achieve  by  manipulating  priorities 
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The  TUF’s  for  the  missile  and  interceptor  control 
updates  change  dynamically  during  the  mission 
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□  1.  Variable  critical  (best)  times  - 
course  corrections  are  needed 
more  often  as  the  distance  between 
target  and  interceptor  decreases 

□  2.  Variable  “hardness”  -  it 
becomes  more  important  to  use  the 
most  recent  position  information  as 
the  distance  between  target  and 
interceptor  decreases 

□  3.  Dynamic  maximum  -  the  utility  of* 
successfully  completing  an 
intercept  corresponds  to  the 
perceived  threat  of  the  target  being 
intercepted 


importance  depending  on  the 
threat  potential  of  the  target, 
independent  of  their  timeliness 
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TUF/UA  scheduling  can  be  very  cost/effective 
in  adaptively  achieving  superior  AQoS 


29 


□  TUF  time  constraints  have  been  shown  to  be  very  natural, 
expressive,  and  powerful  for  the  designers  and  programmers 
of  the  BM/C2  applications  we  have  experimented  with 

□  But  this  paradigm  does  impose  costs 

*  TUF’s  are  more  complex  than  priorities 

*  UA  scheduling  is  more  complex  than  priority  dispatching 

□  Various  application-specific  engineering  techniques  can  be 
used  to  trade  off  costs  vs.  effectiveness 


MITRE 


A  proof  of  concept  software  tool  is  being  produced 
along  with  methodology  and  formalism 
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□  MITRE  and  our  academic  collaborator  Virginia  Tech  are 
developing  a  proof  of  concept  software  tool  for 

•  creating  and  manipulating  TUF’s 

•  plugging  in  various  application-specific  UA  (and  other) 
scheduling  algorithms 

9  simulating  and  analyzing  the  resulting  schedules 

□  One  version  of  this  tool  is  being  done  in  the  context  of  an 
extant  COTS  real-time  timing  analysis  product  - 

the  vendor  is  interested  in  the  commercialization  of  our  work 

□  We  are  also  creating,  simulating,  implementing,  measuring, 
and  proving  properties  of,  new  UA  algorithms  - 

published  and  pre-published  papers  are  available 
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Conclusion 


□  Application  designers  often  think  in  terms  of  what  we  refer  to 
as  AQoS  metrics,  but  not  in  a  general  and  methodological  way 

□  Instead,  they  consider  certain  metrics  and  use  their  domain 
expertise  to  attempt  to  aggregate  these  into  the  proper 
“tuning”  of  the  system 

□  Thus,  they’ve  had  few  incentives  to  use  their  knowledge  to 
understand  and  express  behavioral  options  in  the  face  of 
dynamic  uncertainties  (i.e.,  gracefully  handling  overloads)  to 
facilitate  automated  resource  management 

□  Time/utility  functions  are  more  natural,  expressive,  and 
realistic  for  dynamic  systems,  than  priorities  and  deadlines 

□  AQoS  metrics  can  be  used  to  derive  TUF’s 

□  UA  scheduling  optimality  criteria  are  powerful  and  adaptive 

□  TUF/UA  based  resource  management  has  been  shown  to  be 
very  promising  for  dynamic  systems  such  as  BM/C2 
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